Conventional unified communications (UC) applications support multiple communications modalities including, but not limited to, voice communications (e.g., through integration with a telephone system), voicemail retention and management, video conferencing, meeting scheduling, meeting maintenance, desktop sharing, instant messaging, contacts management (e.g. maintaining a list of contacts of a user of the UC application), presence (e.g. monitoring availability of users of the UC application), group maintenance (e.g., retaining information that identifies groups of the user of the UC application), amongst other communications modalities. The UC application is typically a distributed application, with front-end software executing on client computing devices and back-end software executing on server computing devices, wherein the client computing devices are in network communication with the server computing devices.
Relatively recently, UC applications have been configured to execute on mobile computing devices, such as, mobile telephones, tablets (slates), and the like. The increased use of mobile computing devices, and therefore, the increased use of front-end UC software executing on mobile computing devices, has raised issues not previously associated with UC applications. For example, a data plan corresponding to a mobile telephone may limit an amount of data that can be uploaded and/or downloaded by the mobile computing device (without the user incurring fees that are in addition to monthly plan fees). Further, when using the UC application on a mobile computing device, a user typically causes such application to be executed in foreground for a relatively small amount of time, and subsequently causes the UC application to execute in the background. For instance, the user may participate in a relatively brief meeting through utilization of the UC application executing on the mobile telephone, and thereafter place the telephone in a pocket or bag. In contrast, users of the UC application executing on a desktop computing device tend to allow the application to continuously execute in the foreground.
Conventional tokens utilized to authenticate a user of a UC application tend to be relatively large, such as on the order of 4 kilobytes. If the UC application is configured to cause the user to transmit the token with every request made to servers executing back-end software of the UC application, the relatively large payload of such request (caused at least partially by the relatively large token) can cause the application to execute sub-optimally, and further may result in additional fees being charged to the user for exceeding a data plan. Further, conventional back-end software of UC applications are configured to retain session identifiers for each UC client deemed as being active, wherein the UC client is typically deemed as being active for at least several hours after communicating with a server used in the UC application. Retaining numerous session identifiers limits the scalability of the UC application, in that resources are reserved to maintain session identifiers. Further, with respect to portable computing devices, maintaining session identifiers for long periods of time is wasteful since, as mentioned above, UC application users who log in using mobile computing devices typically do not remain active on the UC application.